Thanks @WhitWaldo!! Same comments on this one:

* remove the python sdk commits,

* sign your commits

* Ensure similarity with the other crypto quickstarts

Same issue as the other - the python commit showed up when I targeted dapr:release-1.15 as it's not on my local branch. Again, should I be targeting a different branch to merge into?

I didn't realize I missed a commit. I'll circle back on that one.

This is the one project I actually read the other quickstarts and I didn't like them as much so I went in another direction. Why would anyone encrypt an image? It made more sense to me to offer practical examples that demonstrated several different techniques offered by the SDK:

• Encryption of a string value
• Encryption of a file-based stream
• Encryption of an in-memory stream

I also considered adding a large-file version generated at runtime (so as not to add to the tree) that demonstrates the bidirectional streaming capability inherent to the SDK (not as easily done with HTTP) as it's been an ask several times for support greater than 4 GB.

This is the one project I actually read the other quickstarts and I didn't like them as much so I went in another direction. Why would anyone encrypt an image? It made more sense to me to offer practical examples that demonstrated several different techniques offered by the SDK:

• Encryption of a string value
• Encryption of a file-based stream
• Encryption of an in-memory stream

I also considered adding a large-file version generated at runtime (so as not to add to the tree) that demonstrates the bidirectional streaming capability inherent to the SDK (not as easily done with HTTP) as it's been an ask several times for support greater than 4 GB.

I agree with your opinion here on a better use case for encryption. That said, I care about consistency and ease of use against the APIs first and foremost. So if we want to improve the quickstarts, I ask for a proposal and/or PR for all the languages, and not just diverge one. In the docs you can literally click/tab through the languages and see the same example in each language.

Agree. please sync again to release-1.15 branch, and also make sure you're not carrying other remnants like the python work. I often do a git reset --hard origin/release-1.15 to force my local repo to sync with origin, and get rid of remnants.

This doesn't appear to be working since I'm not cloning directly from dapr/quickstarts and am instead pushing through whitwaldo/dapr-quickstarts. I don't see any way of forcing GitHub to update any of the upstream branches, so I think I'm just going to have to close this PR, wait for the other PRs to complete, delete the fork and re-fork it to pull the updates.

@alicejgibbons is a better Googler of solutions than I!

This is the one project I actually read the other quickstarts and I didn't like them as much so I went in another direction. Why would anyone encrypt an image? It made more sense to me to offer practical examples that demonstrated several different techniques offered by the SDK:

• Encryption of a string value
• Encryption of a file-based stream
• Encryption of an in-memory stream

I also considered adding a large-file version generated at runtime (so as not to add to the tree) that demonstrates the bidirectional streaming capability inherent to the SDK (not as easily done with HTTP) as it's been an ask several times for support greater than 4 GB.

I agree with your opinion here on a better use case for encryption. That said, I care about consistency and ease of use against the APIs first and foremost. So if we want to improve the quickstarts, I ask for a proposal and/or PR for all the languages, and not just diverge one. In the docs you can literally click/tab through the languages and see the same example in each language.

I'll grant you that it's nice to have the same output values in the docs, but if the goal is to use the test harness to validate that the program actually works, it's not meaningful. Simply confirming in the console that you started with an image and output an image doesn't actually validate that it was encrypted. My PR validates this and doesn't introduce a large artifact into the source tree.

I'd be fine leaving this PR open until such time as the other Crypto PRs can be updated, but I don't have the bandwidth to do this today.

I agree with your opinion here on a better use case for encryption. That said, I care about consistency and ease of use against the APIs first and foremost. So if we want to improve the quickstarts, I ask for a proposal and/or PR for all the languages, and not just diverge one. In the docs you can literally click/tab through the languages and see the same example in each language.

@paulyuk I agree with @WhitWaldo in this case, because after doing an audit of the cryptography quickstarts we are not actually checking the result of the encryption and decryption call to the Dapr api for the file. See the python example below, we are checking that the encryption/decryption of a string works correctly (Passw0rd), but since the test can't validate the image is reproduced correctly after encrypting/decrypting we are stuck just testing that the console lines print out correctly. In Whit's example using a text file we can validate the actual file contents, making it a much better test.

See for example the test here: https://github.com/dapr/quickstarts/blob/master/cryptography/python/sdk/README.md?plain=1#L59-L67

Can we accept Whit's QS here as the "right way" and then make issues to update the other languages? You can assign me this work although I can't promise it'll be done for 1.15 😅